1. Technical Field
The present disclosure relates to an improved use of a generalized input field operated by an entity, such as on a website, social networking site or other user interface. A user can enter input data such as text or an image identifying a product. If a purchase/buy intent is determined, the system provides a buy option to viewers of the image or text. Upon interaction with the buy option, the system processes a payment from the entity and coordinates with a merchant to deliver the item through an application programming interface. This disclosure also focuses on the API itself between the merchant and a browser.
2. Introduction
The current use of input fields, such as the search field on Google™, is simple. The user inputs text related to a search and hits enter or clicks on the search button. Then Google processes the search and returns a list of results. Consider, however, if the user then desires to search Amazon® to purchase an item. The user then must enter the address www.Amazon.com into the URL field of the web browser and hit enter or click “go” or provide some similar input, at which point the web browser contacts Amazon, retrieves the page data, and presents the Amazon web page user interface with a separate search field. The user then enters a search term in that input field and hits enter or clicks on the search button. This is the typical approach where each website has an input field for use in searching under the umbrella of that particular website.
Thus, if a user transitions between doing a Google search, and then making a purchase on Amazon or on eBay, the user must navigate to multiple websites separately, and use multiple, separate input search fields to ultimately make a desired purchase or execute a desired search. The existing paradigm involves first going to a website and then inputting data into the search field of that website.
In some desktop versions of the Opera™ web browser, for example, a user can type into a search field an indicator of what type of search to do. For example, the user can set shortcut codes for various search engines so that a search of “g Olympics” will result in a Google search on the word “Olympics.” Similarly, a search of “b Olympics” results in a Bing® search on the Olympics, while a search of “z Olympics” results in a search of Amazon.com™ on the Olympics. However, these require extra typing, and thus can take longer, and are also only limited to a single search source, and still require the user to navigate through the search results at the requested site. Thus, the user still must perform multiple additional steps to accomplish a desired goal.
Some versions of the Mozilla Firefox™ web browser provide a search field to the side of the URL field. The user can select from different search engines or websites for that search field, such as changing the field to search Google, Wikipedia, Yahoo, Bing, or Amazon. However, this is still cumbersome, as the user must change the field manually between different sites if the user desires to switch search sources.
The same principles above apply to any non-commerce website or site. For example, when a user is on any site or application that is not a commerce application, that user will have to change or manually navigate from the non-commerce site to a commerce site to make a purchase. This is the case for all social media sites that are not designed to sell products but are designed to connect users in particular ways. Twitter, Facebook, Pinterest, Instagram, and other social networking sites are all like this. Their conventional ways of interacting do not enable a user to easily transition to making a purchase or selling a product. This of course is by design, as they are not commerce sites. What is needed is an improved and simplified approach to enabling a transition from any non-commerce site to a commerce experience.